The thin(ish) client revolution

David Berlind: “[P]icture a world where, instead of carrying a notebook computer with you everywhere you go, and instead of having power-drinking desktops in every corner of your house, all you have is a USB key that you take from one dirt cheap thin client to another. On that key is not just all of your personal data (that is stored in the cloud but replicated to your USB key for offline usage), but perhaps a small Web server and some applications, both of which are thin-client friendly.”

I’m in complete agreement that the thin client/web application computing model is the wave of the future, and that the days of the fat client as the primary mechanism for monetizing software are numbered. However, I don’t buy into the notion that software-as-a-service displaces the traditional fat client entirely, for one very simple reason: It’s going to be a while yet before we have truly ubiquitous network connectivity.

Sure, perhaps if you live in the San Francisco Bay area or in a similarly technology centric place, it’s easy to buy into the notion that it won’t be long before we’ll all be connected all the time. However, we can’t lose sight of the fact that a vast majority of the population doesn’t live in a world where technology billboards dominate the morning commute. Heck, my cell phone doesn’t even work when I visit my grandfather in rural Indiana—the notion of an omnipresent wifi fabric built from community hotspots is a long way off there, to put it mildly.

And even when we do get to the day when we have ubiquitous connectivity, we’ll still want caching for optimization and replication to eliminate the single point of failure problem, not to mention the ability to retain control over our own digital lives. So, I view the thin vs. fat client juxtaposition as being not so much about user experience—AJAX has shown us that remarkably good user interfaces can be built on the web. It’ll be more about caching and data replication, two very important considerations in any distributed system. I think most people are missing that. David, as usual, appears to get it.

My prediction: Applications will increasingly move to the web, so you’ll be able to get to your data anytime, anywhere, and from any connected device. No surprise there. But the majority of the time, when you’re using “your” client device (whether it’s a PC in your home or office or a handheld device or something that lives on a USB key and securely attaches to the network via some device that’s outside of your administrative control), you’ll still primarily interact with the web through a fat client of some sort.

To be sure, the fat clients of the future will look a lot different from the fat clients of today. Hint: “Fat client” doesn’t have to mean “self-administered”. Perhaps the fat clients of the future are delivered on demand or via independently developed components that integrate into some larger framework. Perhaps it’s as simple as running a web server locally. But the fat client in whatever form will still be the primary interface the vast majority of the time. That’s why I don’t buy for a minute that Web 2.0 is yet another death knell for Microsoft. They’ve obviously got a great fat client story, and in case you haven’t noticed, they’ve just woken up to what’s going on around them.

By the way, this is the area where I think Linux on the desktop could have the biggest impact—it won’t be about who has the better desktop or who can replicate the popular fat client applications of today in open source. It’ll be about who can mold Linux into the fat client framework of the future, seamlessly integrated with applications and services delivered via the web but open. If I were Microsoft’s competitors in this space, namely Google and Yahoo, I’d be spending a lot of time thinking about this. In today’s fat client world, Microsoft is between them and their customers more often than not, and if the past is any indication, they’ll be able to use this position to tremendous advantage.

No good deed goes unpunished

One of the big Debian stories of the week is that a company called Nexenta Systems has made a version of Ubuntu that’s based on OpenSolaris rather than the Linux kernel. Personally, I find the emergence of a Debian-based OpenSolaris distribution exciting, as it promises to vastly improve Solaris installation, packaging, and overall usability. Solaris is great technology with an incredible pedigree and some very compelling features (DTrace, in particular, sounds like a godsend, as I’m sure anyone who’s debugged kernel code via endless iterations of inserting printfs at strategic places would agree), not to mention that it’s now open source. However, when a Linux developer eager to have a look at all this neat new open source stuff boots up Solaris for the first time, it’s a bit of a throwback to an earlier time (not to mention the fact that apt-get is a hard habit to break..).

And, so, I’m more than a little embarrassed at how certain members of the Debian community reacted to Nexenta’s work. The vitriol surprised even me, knowing as much as I know about how, uh, strongly the Debian community feels about certain issues. The issue in this case: Nexenta links GPL-licensed programs (including dpkg) with the Sun C library, which is licensed under the GPL-incompatible but still free software/open source CDDL license. Granted, Nexenta didn’t go about introducing themselves to the Debian community in the best way, and there may (may) be issues around whether or not what they are doing is permitted by the GPL, but couldn’t we at least engage them in a more constructive manner?

In terms of the actual issue being discussed here, am I the only one who doesn’t get it? It seems to me the argument that linking a GPL application to a CDDL library and asserting that that somehow makes the library a derivative work of the application is, to say the least, a stretch—not to mention the fact that we’re talking about libc here, a library with a highly standard interface that’s been implemented any number of times and, heck, that’s even older than the GPL itself. It’s interpretations like this, folks, that give the GPL its reputation of being viral, and I know how much Richard Stallman hates that word. It’s one thing to ensure that actual derivative works of GPL code are themselves licensed under similar terms; it’s quite another to try to apply the same argument to code that clearly isn’t a derivative work in an attempt to spread free software at any cost. I’ve been a big GPL advocate for a long time, but that just strikes me as wrong.

BlogDaddy

Larry Murdock: “Blogging is a better way of disseminating one’s thoughts than sitting on the bench in front of the County Courthouse whittling and shooting the breeze with a couple of old-timers.”

Dad’s been forwarding me interesting bits he reads on the web with his own insights attached for years, and I finally convinced him to put these kinds of things in a blog so the rest of the world can enjoy them too. Dad’s an excellent writer and is one of the most creative, articulate, and intelligent people I’ve ever known (though he seemed remarkably stupid between about 1987 and 1991, when I briefly knew more about the world than he did). I owe him a lot.

Battle lines

More David Berlind: “Maybe I’m crazy. But if you ask me, there’s a super big picture that’s begining to form when you start to look at all of this week’s announcements, or maybe-announcements involving Google, AOL, Real, Microsoft, Apple, Yahoo, Sun and more. If I’m not mistaken, just about everyone is taking sides in preparation for what appears to be a two-way show down with an odd-man out.”

What’s in a name?

Following time-honored tradition, “DCC” is now a recursive acronym that stands for “DCC Common Core”. Importantly, “DCC” no longer stands for “Debian Common Core”, and we’ve updated the FAQ accordingly. If you see further references to “Debian Common Core” in the press, feel free to send them a link to this page or ask them to contact me.

Why are we doing this? The DCC is a truly important initiative for Debian, and we don’t want continued controversy over what we chose to call it to overshadow the real message of the DCC, namely that Debian is ready for enterprise use.

In related news, we’re in the process of trying to make the DCC (or at least the technical aspects of it) an official Debian subproject—see the debian-enterprise Alioth project if you’re interested in Debian in the enterprise and want to get involved.

When is a fork not a fork?

Matthew: Is the DCC a fork? Not by the standard definition of the term:

[A] fork is what occurs when two (or more) versions of a software package’s source code are being developed in parallel which once shared a common code base, and these multiple versions of the source code have irreconcilable differences between them.

Perhaps you use a different definition, so I’ll outline the differences between Debian and the DCC, and you (and others) can decide for yourself:

  1. Back of the envelope, the DCC contains 234 packages, of which 205 (87.6%) are taken from Debian sarge unmodified (as of DCC 3.0 PR1).
  2. Of the remaining 29 packages, 4 are the LSB 3.0 compatibility environment, which adds LSB 3.0 compliance in such a way that the sarge glibc and pam packages don’t need to be modified (the sarge versions aren’t LSB 3.0 compliant—see Jeff Licquia’s weblog for details here and here). Note that the only applications that use the LSB compatibility environment are LSB applications—the default application environment is the standard Debian environment.
  3. Of the remaining 25 packages, 19 are a backport of X.org from etch (again, as of DCC 3.0 PR1—there will be additional X.org packages in PR2). The DCC X.org environment is fully compatible with the standard Debian XFree86 environment—in other words, packages built on DCC-based distros will install and run on standard Debian sarge unless they use X.org-specific features (in which case they will link to one of the new X.org packages, such as libxcomposite1 or libxdamage1, not shipped in the DCC itself).
  4. The remaining 6 packages are backports of the LSB 3.0 packages from etch (lsb, lsb-base, lsb-core, lsb-cxx, lsb-graphics, and lsb-release), modified to 1. not manage the LSB dynamic linker symlinks (these are managed by the DCC LSB compatibility environment); and 2. add LSB_VERSION=3.0 to /etc/lsb-release, since DCC 3.0 is LSB 3.0 compliant.
  5. The kernel is Linux 2.6.12.5 from etch built using the standard Debian kernel build tools and with the following additional patches applied: acpi, bootsplash, ppp_mppe, sk98lin, and win4lin.

    The following kernel images are provided: 586tsc (standard x86), p4-smp (Pentium 4 with SMP support), k7-smp (Athlon with SMP support), mckinley-smp (Itanium II with SMP support), and amd64-generic (AMD64 and EM64T).

That’s it. Does that constitute a fork? Given that nearly 90% is bit-identical with sarge and the vast majority of the remainder are very lightly modified backports from etch, I wouldn’t call it a fork, but that’s just me.

Furthermore, there’s no parallel development going on, just integration work, and the differences that do exist are very minor and certainly aren’t irreconcilable.

By the way, as I’ve said before, I have no problems with forking, as long as it’s done with compatibility in mind, something the DCC is clearly doing:

My suggestions are a simple way to mitigate the inevitable compatibility problems of a fork without taking away the freedom to fork (which has never been a problem from my point of view, by the way—unlike most people in the free software world, I don’t spend a lot of time wringing my hands over the forking issue—it is, after all, one of the fundamental freedoms of free software).

Back to work. Again.

DCC progress

Things have been quiet on the DCC Alliance front lately, but that’s because we’ve been working to deliver what we said we’d deliver at LinuxWorld last month—we certainly don’t want to come across as big on talking about how much we’re going to help Debian, but lacking any actual contributions yet. After all, code talks and bullshit walks.

In that spirit, here’s an update on our progress:

First and foremost, the first preview release of the DCC, DCC 3.0 PR1, was made available late last week. PR1 supports the i386 architecture.

DCC 3.0 PR2 will be made available late this week or early next week. PR2 adds support for the ia64 and amd64 architectures and fixes a handful of bugs in PR1.

We expect to achieve full LSB 3.0 compliance with PR2 and be very close to the final DCC 3.0 ready for LSB 3.0 certification.

Technical details as of PR1 are in the release announcement; I’ll post the PR2 release announcement with final technical details here.

Technical issues are being discussed on an open mailing list. Feel free to join and participate:

http://lists.dccalliance.org/mailman/listinfo/dcc-devel

We’ve also created a general discussion list for non-technical issues, including, but not limited to, our flagrant misappropriation of the letter D:

http://lists.dccalliance.org/mailman/listinfo/dcca-discuss

Back to work.